%% main.tex --- файл-обертка для диплома

\documentclass[russian,utf8,simple,floatsection,equationsection]{eskdtext} 

\include{defs}  % вставляем содержимое служебных инструкций из defs.tex

\setcounter{section}{3}

\ESKDcolumnII{\normalsize{Проектирование и разработка алгоритмов и структур данных}}

\begin{document}
\section{Проектирование и разработка алгоритмов и структур данных.}
\subsection{Проектирование базы данных}
\subsubsection{Концептуальная схема }

Реляционная модель данных в подавляющем большинстве случаев вполне
достаточна для моделирования любых данных. Однако проектирование базы
данных в терминах схемы отношений на практике может вызвать большие
затруднения, т.к. в этой модели изначально не предусмотрены механизмы
описания семантики предметной области. С этим связано появление
семантических моделей данных, которые позволяют описать конкретную
предметную область гораздо ближе к интуитивному пониманию и, в то же
время, достаточно формальным образом.


Часто семантическое моделирование используется только на первой стадии
проектирования базы данных. Концептуальная схема будущей БД строится
на основе некоторой семантической модели, а затем вручную
преобразуется к реляционной схеме.


Существуют методики, четко описывающие все этапы такого преобразования.

При таком подходе отсутствует потребность в дополнительных программных
средствах, поддерживающих семантическое моделирование. Требуется
только владение основами выбранной семантической модели и правилами
преобразования концептуальной схемы в реляционную.

Следует заметить, что многие начинающие проектировщики баз данных
недооценивают важность семантического моделирования вручную. Зачастую
это воспринимается как дополнительная и излишняя работа. Эта точка
зрения является абсолютно неверной. Во-первых, построение мощной и
наглядной концептуальной схемы БД позволяет более полно оценить
специфику моделируемой предметной области и избежать возможных ошибок
на стадии проектирования схемы реляционной БД. Во-вторых, на этапе
семантического моделирования производится очень важная документация
(хотя бы в виде вручную нарисованных диаграмм и комментариев к ним),
которая может оказаться полезной не только при проектировании схемы
реляционной БД, но и при эксплуатации, сопровождении и развитии уже
заполненной БД. 

Следует заметить, что многие начинающие проектировщики баз данных
недооценивают важность семантического моделирования вручную. Зачастую
это воспринимается как дополнительная и излишняя работа. Эта точка
зрения абсолютно неверна. Во-первых, построение мощной и наглядной
концептуальной схемы БД позволяет более полно оценить специфику
моделируемой предметной области и избежать возможных ошибок на стадии
проектирования схемы реляционной БД. Во-вторых, на этапе
семантического моделирования производится важная документация (хотя бы
в виде вручную нарисованных диаграмм и комментариев к ним), которая
может оказаться очень полезной не только при проектировании схемы
реляционной БД, но и при эксплуатации, сопровождении и развитии уже
заполненной БД.

Концептуальная схема данных представлена на рисунке~\ref{db_concept}.

\begin{figure}[!ht]
  \centering
  \includegraphics[angle=0, width=\textwidth]{db_concept}
  \caption{Концептуальная схема базы данных.}
  \label{db_concept}
\end{figure}

Сущности, представленные на диаграмме:

\begin{enumerate}
\item Предмет;
\item Преподаватель;
\item Пользователи;
\item Электронная литература;
\item Методичка;
\item Лабораторная;
\item Курсовой проект;
\item Курсовая работа;
\item Список литературы;
\end{enumerate}

\subsubsection{Системный анализ}
Следующим этапом разработки программного обеспечения является
проектирование базы данных.

Основными этапами проектирования базы данных являются:
\begin{itemize}
\item Системный анализ;
\item Инфологическое проектирование;
\item Логическое проектирование.
\end{itemize}

Сутью системного анализа является определение задач, которые решаются
в системе и для кого. Представим объекты системы:
\begin{itemize}
\item Предмет;
\item Преподаватель;
\item Пользователи;
\item Электронная литература;
\item Методичка;
\item Лабораторная;
\item Курсовой проект;
\item Курсовая работа;
\item Список литературы.
\end{itemize}

Атрибутами параметров <<Предмет>> являются:
\begin{itemize}
\item Название;
\item Имя преподавателя;
\item Семестр, в котором он ведется.
\end{itemize}

Атрибутами параметров <<Электронная литература>> являются:
\begin{itemize}
\item Название;
\item Содержание;
\item Тема;
\item Текст.
\end{itemize}

Атрибутами параметров <<Методичка>> являются:
\begin{itemize}
\item Название;
\item Содержание;
\item Тема;
\end{itemize}

Атрибутами параметров <<Лабораторная работа>> являются:
\begin{itemize}
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Атрибутами параметров <<Курсовая работа>> являются:
\begin{itemize}
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Атрибутами параметров <<Курсовой проект>> являются:
\begin{itemize}
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Атрибутами параметров <<Список литературы>> являются:
\begin{itemize}
\item Название;
\item BibTeX.
\end{itemize}

Атрибутами параметров <<Преподаватель>> являются:
\begin{itemize}
\item Имя;
\item Фамилия;
\item Отчество;
\item Предметы.
\end{itemize}

Атрибутами параметров <<Пользователи>> являются:
\begin{itemize}
\item login;
\item password(sha1);
\item права ( 1- привилегированный пользователь, 0 - обычный).
\end{itemize}

\subsubsection{Инфологическое проектирование}
Инфологическая модель применяется на втором этапе проектирования БД,
то есть после словесного описания предметной области. При разработке
серьезных корпоративных информационных систем проект базы данных
является тем фундаментом, на котором строится вся система в
целом. Следовательно, инфологическая модель должна включать такое
формализованное описание предметной области, которое легко будет
<<читаться>> не только специалистами по базам данных, и это описание
должно быть настолько емким, чтобы можно было оценить глубину и
корректность проработки проекта БД, и конечно оно не должно быть
привязано к конкретной СУБД. Инфологическое проектирование, прежде
всего, связано с попыткой представления семантики предметной области в
модели БД. Реляционная модель данных в силу своей простоты и
лаконичности не позволяет отобразить семантику, то есть смысл
предметной области. Ранние теоретико-графовые модели в большей степени
отображали семантику предметной области. Они в явном виде определяли
иерархические связи между объектами предметной области. Проблема
представления семантики давно интересовала разработчиков, и в
семидесятых годах было предложено несколько моделей данных, названных
семантическими моделями. К ним можно отнести семантическую модель
данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981
году, функциональную модель данных Шипмана (Shipman), также созданную
в 1981 году \red{[5]}, модель <<сущность-связь>>, предложенную Ченом (Chen) в
1976 году, и ряд других моделей. У всех моделей были свои
положительные и отрицательные стороны, но испытание временем выдержала
только последняя. И в настоящий момент именно модель Чена
<<сущность-связь>>, пли <<Entity Relationship>>, стала фактическим
стандартом при инфологическом моделировании баз данных. Общепринятым
стало сокращенное название ER-модель, большинство современных
CASE-средств содержат инструментальные средства для описания данных в
формализме этой модели. Кроме того, разработаны методы автоматического
преобразования проекта БД из ER-модели в реляционную, при этом
преобразование выполняется в дата-логическую модель, соответствующую
конкретной СУБД. Все CASE-системы имеют развитые средства
документирования процесса разработки БД, автоматические генераторы
отчетов позволяют подготовить отчет о текущем состоянии проекта БД с
подробным описанием объектов БД и их отношений, как в графическом
виде, так и в виде готовых стандартных печатных отчетов, что
существенно облегчает ведение проекта.  

В настоящий момент не существует единой общепринятой системы
обозначений для ER-модели и разные CASE-системы используют разные
графические нотации, но разобравшись в одной, можно легко понять и
другие нотации \red{[5]}.

\emph{Модель <<сущность—связь>>}

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или
entity-relationship diagram ) — это модель данных, позволяющая
описывать концептуальные схемы. Она предоставляет графическую нотацию,
основанную на блоках и соединяющих их линиях, с помощью которых можно
описывать объекты и отношения между ними какой-либо другой модели
данных. В этом смысле ER-модель является мета-моделью данных, то есть
средством описания моделей данных. Как любая модель, модель
<<сущность—связь>> имеет несколько базовых понятий, которые образуют
исходные кирпичики, из которых строятся уже более сложные объекты по
заранее определенным правилам. Эта модель в наибольшей степени
согласуется с концепцией объектно-ориентированного проектирования,
которая в настоящий момент, несомненно, является базовой для
разработки сложных программных систем \red{[6]}.

В основе ER-модели лежат следующие базовые понятия:
Сущность имеет имя, уникальное в пределах моделируемой системы. Так
как сущность соответствует некоторому классу однотипных объектов, то
предполагается, что в системе существует множество экземпляров данной
сущности. Объект, которому соответствует понятие сущности, имеет свой
набор атрибутов — характеристик, определяющих свойства данного
представителя класса. При этом набор атрибутов должен быть таким,
чтобы можно было различать конкретные экземпляры сущности. Например, у
сущности Сотрудник может быть следующий набор атрибутов: табельный
помер, фамилия, имя, отчество, дата рождения, количество детей. Набор
атрибутов, однозначно идентифицирующий конкретный экземпляр сущности,
называют ключевым. Для сущности Сотрудник ключевым будет атрибут
табельный номер, поскольку для всех сотрудников данного предприятия
табельные номера будут различны. Экземпляром сущности Сотрудник будет
описание конкретного сотрудника предприятия. Одно из общепринятых
графических обозначений сущности - прямоугольник, в верхней части
которого записано имя сущности, а ниже перечисляются атрибуты. Между
сущностями могут быть установлены связи - бинарные ассоциации,
показывающие, каким образом сущности соотносятся или взаимодействуют
между собой. Связь может существовать между двумя разными сущностями
пли между сущностью и ей же самой (рекурсивная связь). Она показывает,
как связаны экземпляры сущностей между собой. Если связь
устанавливается между двумя сущностями, то она определяет взаимосвязь
между экземплярами одной и другой сущности. Например, если у пас есть
связь между сущностью <<Студент>> и сущностью <<Преподаватель>> и эта
связь — руководство дипломными проектами, то каждый студент имеет
только одного руководителя, но один и тот же преподаватель может
руководить множеством студентов-дипломников. Поэтому это будет связь
<<один-ко-многим>> (1:$\infty$), один со стороны <<Преподаватель>> и многие со
стороны <<Студент>>. Связи делятся на три типа по множественности:
один-к-одному (1:1), один-ко-многим (1:$\infty$), многие-ко-многим
($\infty$:$\infty$). Связь один-к-одному (1:1) означает, что экземпляр одной
сущности связан только с одним экземпляром другой сущности. Связь (1:
$\infty$) означает, что один экземпляр сущности, расположенный слева по
связи, может быть связан с несколькими экземплярами сущности,
расположенными справа по связи. А связь <<многие-ко-многим>> ($\infty$:$\infty$)
означает, что один экземпляр первой сущности может быть связан с
несколькими экземплярами второй сущности, и наоборот, один экземпляр
второй сущности может быть связан с несколькими экземплярами первой
сущности.  

Между двумя сущностями может быть задано сколько угодно связей с
разными смысловыми нагрузками.

На основе этих данных опишем сущности, присутствующие в базе данных.

Сущность <<Предмет>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Название;
\item Имя преподавателя;
\item Семестр, в котором он ведется.
\end{itemize}

Сущность <<Электронная литература>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Название;
\item Содержание;
\item Тема;
\item Текст.
\end{itemize}

Сущность <<Методичка>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Название;
\item Содержание;
\item Тема.
\end{itemize}

Сущность <<Лабораторная работа>>.
Атрибутами  являются:
\begin{itemize}
\item id ;
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Сущность  <<Курсовая работа>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Сущность <<Курсовой проект>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Номер;
\item Тема;
\item Текст;
\item Предмет;
\item Семестр;
\item Пример выполнения.
\end{itemize}

Сущность <<Список литературы>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Название;
\item BibTeX.
\end{itemize}

Сущность <<Преподаватель>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item Имя;
\item Фамилия;
\item Отчество;
\item Предметы.
\end{itemize}

Сущность <<Пользователи>>.
Атрибутами являются:
\begin{itemize}
\item id ;
\item login;
\item password(sha1);
\item права ( 1- привилегированный пользователь, 0 - обычный).
\end{itemize}

В результате построения модели предметной области в виде набора
сущностей и связей получаем связный граф.

\subsubsection{Логическое проектирование}

Схемы базы данных представлена на рисунке~\ref{db}

\begin{figure}[!ht]
  \centering
  \includegraphics[angle=0, width=\textwidth]{db}
  \caption{ER диаграмма базы данных.}
  \label{db}
\end{figure}

Для создания этих таблиц, использовались следующие SQL запросы: 

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_subject" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL
);
\end{lstlisting}

\begin{description}
\item[name] - имя
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_methods" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "content" text NOT NULL
);
\end{lstlisting}

\begin{description}
\item[name] - имя
\item[content] - содержание
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_eliter" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "content" text NOT NULL
);
\end{lstlisting}

\begin{description}
\item[name] - имя
\item[content] - содержание
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_lab" (
    "id" integer NOT NULL PRIMARY KEY,
    "number" integer NOT NULL,
    "theme" varchar(255) NOT NULL,
    "text" text NOT NULL,
    "semester" integer NOT NULL
);
\end{lstlisting}

\begin{description}
\item[number] - номер
\item[theme] - тема
\item[text]  - содержимое
\item[semester]  - номер семестра
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_courseproject" (
    "id" integer NOT NULL PRIMARY KEY,
    "number" integer NOT NULL,
    "theme" varchar(255) NOT NULL,
    "text" text NOT NULL,
    "subject_id" integer NOT NULL 
                 REFERENCES "library_subject" ("id"),
    "semester" integer NOT NULL
);
\end{lstlisting}

\begin{description}
\item[number] - номер
\item[theme] - тема
\item[text]  - содержимое
\item[semester]  - номер семестра
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_coursework" (
    "id" integer NOT NULL PRIMARY KEY,
    "number" integer NOT NULL,
    "theme" varchar(255) NOT NULL,
    "text" text NOT NULL,
    "subject_id" integer NOT NULL 
                       REFERENCES "library_subject" ("id"),
    "semester" integer NOT NULL
);
\end{lstlisting}

\begin{description}
\item[number] - номер
\item[theme] - тема
\item[text]  - содержимое
\item[semester]  - номер семестра
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_literlist" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL
);
\end{lstlisting}

\begin{description}
\item[name] - имя
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_right" (
    "id" integer NOT NULL PRIMARY KEY,
    "login" varchar(255) NOT NULL,
    "password" varchar(255) NOT NULL,
    "uid" integer NOT NULL
);
\end{lstlisting}

\begin{description}
\item[lgin] - логин
\item[password] - пароль
\item[uid]  - права доступа
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_prepod" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "sname" varchar(255) NOT NULL,
    "fatherName" varchar(255) NOT NULL
);
\end{lstlisting}

\begin{description}
\item[name] - имя
\item[sname]  - фамилия
\item[fatherName] - отчество 
\end{description}

\begin{lstlisting}[language=SQL]
CREATE TABLE "library_methods_subject" (
    "id" integer NOT NULL PRIMARY KEY,
    "methods_id" integer 
          NOT NULL REFERENCES "library_methods" ("id"),
    "subject_id" integer 
          NOT NULL REFERENCES "library_subject" ("id"),
    UNIQUE ("methods_id", "subject_id")
);

CREATE TABLE "library_eliter_subject" (
    "id" integer NOT NULL PRIMARY KEY,
    "eliter_id" integer 
          NOT NULL REFERENCES "library_eliter" ("id"),
    "subject_id" integer 
          NOT NULL REFERENCES "library_subject" ("id"),
    UNIQUE ("eliter_id", "subject_id")
);

CREATE TABLE "library_eliter_methods" (
    "id" integer NOT NULL PRIMARY KEY,
    "eliter_id" integer 
           NOT NULL REFERENCES "library_eliter" ("id"),
    "methods_id" integer 
           NOT NULL REFERENCES "library_methods" ("id"),
    UNIQUE ("eliter_id", "methods_id")
);

CREATE TABLE "library_lab_subject" (
    "id" integer NOT NULL PRIMARY KEY,
    "lab_id" integer 
         NOT NULL REFERENCES "library_lab" ("id"),
    "subject_id" integer 
         NOT NULL REFERENCES "library_subject" ("id"),
    UNIQUE ("lab_id", "subject_id")
);

CREATE TABLE "library_lab_liter" (
    "id" integer NOT NULL PRIMARY KEY,
    "lab_id" integer 
          NOT NULL REFERENCES "library_lab" ("id"),
    "eliter_id" integer 
          NOT NULL REFERENCES "library_eliter" ("id"),
    UNIQUE ("lab_id", "eliter_id")
);

CREATE TABLE "library_courseproject_liter" (
    "id" integer NOT NULL PRIMARY KEY,
    "courseproject_id" integer 
         NOT NULL REFERENCES "library_courseproject" ("id"),
    "eliter_id" integer 
         NOT NULL REFERENCES "library_eliter" ("id"),
    UNIQUE ("courseproject_id", "eliter_id")
);

CREATE TABLE "library_coursework_liter" (
    "id" integer NOT NULL PRIMARY KEY,
    "coursework_id" integer 
          NOT NULL REFERENCES "library_coursework" ("id"),
    "eliter_id" integer 
          NOT NULL REFERENCES "library_eliter" ("id"),
    UNIQUE ("coursework_id", "eliter_id")
);

CREATE TABLE "library_literlist_subject" (
    "id" integer NOT NULL PRIMARY KEY,
    "literlist_id" integer 
          NOT NULL REFERENCES "library_literlist" ("id"),
    "subject_id" integer 
          NOT NULL REFERENCES "library_subject" ("id"),
    UNIQUE ("literlist_id", "subject_id")
);

CREATE TABLE "library_prepod_subjects" (
    "id" integer NOT NULL PRIMARY KEY,
    "prepod_id" integer 
          NOT NULL REFERENCES "library_prepod" ("id"),
    "subject_id" integer 
          NOT NULL REFERENCES "library_subject" ("id"),
    UNIQUE ("prepod_id", "subject_id")
);

CREATE TABLE "library_prepod_rights" (
    "id" integer NOT NULL PRIMARY KEY,
    "prepod_id" integer 
          NOT NULL REFERENCES "library_prepod" ("id"),
    "right_id" integer 
          NOT NULL REFERENCES "library_right" ("id"),
    UNIQUE ("prepod_id", "right_id")
);

CREATE TABLE "library_prepod_liter" (
    "id" integer NOT NULL PRIMARY KEY,
    "prepod_id" integer 
           NOT NULL REFERENCES "library_prepod" ("id"),
    "eliter_id" integer 
            NOT NULL REFERENCES "library_eliter" ("id"),
    UNIQUE ("prepod_id", "eliter_id")
);

CREATE INDEX "library_courseproject_subject_id" 
         ON "library_courseproject" ("subject_id");
CREATE INDEX "library_coursework_subject_id" 
         ON "library_coursework" ("subject_id");
\end{lstlisting}


\subsection{Проектирование диаграммы классов}

UML (сокр. от англ. Unified Modeling Language — унифицированный язык
моделирования) — язык графического описания для объектного
моделирования в области разработки программного обеспечения. UML
является языком широкого профиля, это открытый стандарт, использующий
графические обозначения для создания абстрактной модели системы,
называемой UML моделью. UML был создан для определения, визуализации,
проектирования и документирования в основном программных систем. UML
не является языком программирования, но в средствах выполнения
UML-моделей как интерпретируемого кода возможна кодогенерация.

Использование UML не ограничивается моделированием программного
обеспечения. Его также используют для моделирования бизнес-процессов,
системного проектирования и отображения организационных структур.

UML позволяет также разработчикам программного обеспечения достигнуть
соглашения в графических обозначениях для представления общих понятий
(таких как класс, компонент, обобщение (generalization), объединение
(aggregation) и поведение) и больше сконцентрироваться на
проектировании и архитектуре.

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational
Software, объединили свои усилия для создания нового языка
объектно-ориентированного моделирования. За основу языка ими были
взяты методы моделирования, разработанные Бучем (Booch) и Рамбо
(Object-Modeling Technique — OMT). OMT был ориентирован на анализ, а
Booch — на проектирование программных систем. В октябре 1995 года была
выпущена предварительная версия 0.8 унифицированного метода
(англ. Unified Method). Осенью 1995 года к компании Rational
присоединился Айвар Якобсон, автор метода Object-Oriented Software
Engineering — OOSE. OOSE обеспечивал превосходные возможности для
спецификации бизнес-процессов и анализа требований при помощи
сценариев использования. OOSE был также интегрирован в унифицированный
метод.

На этом этапе основная роль в организации процесса разработки UML
перешла к консорциуму OMG (Object Management Group). Группа
разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон,
выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996
года.

На волне растущего интереса к UML к разработке новых версий языка в
рамках консорциума UML Partners присоединились такие компании, как
Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp,
IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation,
Rational Software, Texas Instruments и Unisys. Результатом совместной
работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В
ноябре того же года за ней последовала версия 1.1, содержавшая
улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные,
соответственно в июне 1999, сентябре 2001 и марте 2003 года.

Формальная спецификация последней версии UML 2.0 опубликована в
августе 2005 года. Семантика языка была значительно уточнена и
расширена для поддержки методологии Model Driven Development — MDD
(англ.).

UML 1.4.2 принят в качестве международного стандарта ISO/IEC
19501:2005.

Диаграмма классов, Class diagram — статическая структурная диаграмма,
описывающая структуру системы, она демонстрирует классы системы, их
атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в
зависимости от целей их применения:

\begin{itemize}
\item концептуальная точка зрения — диаграмма классов описывает модель
  предметной области, в ней присутствуют только классы прикладных
  объектов;
\item точка зрения спецификации — диаграмма классов применяется при
  проектировании информационных систем;
\item точка зрения реализации — диаграмма классов содержит классы,
используемые непосредственно в программном коде (при использовании
объектно-ориентированных языков программирования).
\end{itemize}

Диаграмма разработанной системы представлена на
рисунке~\ref{fig:uml-diagram}.

\begin{figure}[!ht]
  \centering
  \includegraphics[angle=0, width=\textwidth]{uml-diagram}
  \caption{UML диаграмма разработанной системы}
  \label{fig:uml-diagram}
\end{figure}

Класс \textbf{model} это стандартный класс для представления таблиц в
Django.

Классы \textbf{Subject,Methods,Eliter,CourseProject,CourseWork,Rights}
соответствуют одноименным таблица из разработанной базы данных.

\end{document}
